fix:In scenarios involving languages such as Chinese, Japanese, and K… - #73

Thanks for the PR and the detailed screenshots — you've correctly identified the root cause: the webview renders non-ASCII hrefs percent-encoded, so the extension tries to open a file literally named %E7%AC%AC....

Two problems with the current approach, though:

1. Wrong layer. openFile in src/extension.ts already validates the path via isSafeRelPath(), which calls decodeURIComponent before checking for traversal. Decoding in the webview means the path we validate (decoded twice) and the path we open (decoded once) differ — fragile and easier to get wrong. The fix belongs on the extension side: decode once after validation and pass the decoded path to joinPath. This also fixes local images (![第一章](第一章/x.png)), which are broken by the same double-encoding.

2. Your example still wouldn't work. [第一章](/第一章/第一章.md) is a link starting with /. Since 0.2.12 we deliberately reject webview-requested paths that resolve to the filesystem root (security hardening). The docs convention here is relative links: [第一章](第一章/第一章.md). (/path links happened to work before 0.2.12, but that was an accident of Uri.joinPath, not intended behavior — we're keeping the rejection.)

Could you rework the fix in src/extension.ts instead — decode the path once in openFile (and ideally localImage) after the isSafeRelPath check, wrapped in try/catch for malformed sequences like 50%-off.md? Happy to help if you hit issues. Otherwise I can take it from here and credit you for the report.